Description

• Added Tracy profiler client (0.11.1) as a dependency. This allows us to mark scopes we want to profile, and visualize profiling data using the Tracy server (.exe)
• Added support for GPU profiling with Tracy (using OpenGL queries).
• Added memory profiling
• Added lua script profiling
• Removed OvAnalytics (profiling is now done by Tracy)
• Remove Profiler editor panel
  • Moved Framerate Counter from Profiler (not removed) to FrameInfo

Tracy is AWESOME! The best part is, the GUI is an external tool, so it doesn't bloat the engine!

Review Guidance

• Tracy requires us to set the TRACY_ENABLE define globally (Overload/premake5.lua)
• Also added a TRACY_MEMORY_ENABLE define to toggle memory profiling
• C++ Hot Reload (premake: editandcontinue "Off") had to be disabled for Tracy to work (Overload/premake5.lua)
• To test this feature, get the Tracy server (0.11.1), run it, connect, and voila!
• I had to implement a workaround for memory profiling (in FrameInfo.cpp), since using std::format with a non-default std::locale seems to cause an instrumentation failure with Tracy (std::format might be calling delete on a non-allocated memory region)
• Download Tracy documentation: https://github.com/wolfpld/tracy/releases/latest/download/tracy.pdf

Limitations/Regressions

• Adding the tracy-profiler.exe (Tracy server) to the repository increase its size from 17MB to about 38MB.
• std::locale not working properly with tracy memory profiling, frame info numbers aren't formatted following the user regional settings (i.e., for en_US, no more thousand separator if tracy is enabled)
  • An option could also be to disable tracy memory profiling outside of Debug builds.
• Since we are shipping a Windows executable (tracy-profiler.exe), it will make it harder to port Overload to linux. Building the server ourselves would be ideal, but given its dependencies, it might be more of a headache.
• All builds are profilable, debug & release. In a follow-up PR we should update our configurations to generate builds with profiling disabled. But because tracy has a pretty low impact on performance, it's ok for now to just leave it ON

To-Do

• Add more markers/scopes
• Consider updating our PROFILER_SPY to also use Tracy under the hood, so that we can profile a scope with a single macro (or alternatively, get rid of PROFILER_SPY 😆)
• Should we ship Tracy server with Overload? Maybe it could be a submodule (so if you want it, you initialize the submodule)
• Adding memory profiling
• Add lua profiling support
• Add aligned new operator overload (doesn't seem to solve the issue with std::format so far. discussion link)
• Should we disable profiling in Release? will be addressed in a follow-up PR, for now, all builds are "profilable"

Related Issues

Closes #421
Closes #332
Closes #333
Closes #292
Closes #107

Screenshots